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1  Introduction 

High-Level  synthesis  is  the  transformation  from  a  behavioral  level  specification 
of  hardware  to  a  register  transfer  level  description,  which  may  then  be  mapped 
to  a  VLSI  implementation.  The  success  of  high-level  synthesis  systems  is  heavily 
dependent  on  how  effectively  the  behavioral  language  captures  the  ideas  of  the 
designer  in  a  simple  and  understandable  way.  This  paper  describes  Hardware C. 
a  behavioral  hardware  description  language  that  is  used  by  the  HERCULES 
High-Level  Synthesis  system  [1,2). 

The  input  to  HERCULES  consists  of  two  sets  of  specifications  -  a  description 
of  the  fwnciionahty  and  a  set  of  design  constraints.  The  functionality  is  described 
in  a  C-based  language  extended  for  hardware  description  called  Hardware  C.  The 
design  constraints  specify  the  timing  and  resource  limitations  that  are  imposed 
on  a  given  design.  The  HardwareC  description  is  parsed  and  translated  into 
a  parse  tree  abstraction  called  the  behavioral  intermediate  form,  which  is  the 
basis  for  behavioral  synthesis.  Behavioral  synthesis  performs  transformations 
similar  to  those  found  in  optimizing  compilers.  Upon  completion  of  behavioral 
synthesis,  the  optimized  intermediate  form  is  mapped  to  a  register  transfer  level 
implementation. 


2  Motivations 

Many  hardware  description  languages  have  been  proposed  and  used  in  both 
academia  and  in  industry.  Most  hardware  description  languages  are  oriented 
towards  simulation.  As  high-level  synthesis  systems  mature,  a  need  arises  for 
languages  that  aid  not  only  in  the  simulation  of  hardware,  but  also  in  its  design 
as  well. 
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Several  criteria  most  be  met  by  a  language  for  hardware  design,  they  are 
described  below. 

1.  Supports  full  sptdrum  of  design  styles. 

The  language  should  support  readily  the  varying  spectrum  of  design  styles 
of  the  designer,  ranging  from  a  pure  behavioral  description  that  is  inde¬ 
pendent  of  the  structural  implementation,  to  a  mixture  of  behavior  and 
structure,  to  a  pure  structural  description  of  the  interconnection  and  in¬ 
stantiation  of  hardware  modules. 

This  criterion  is  crucial  in  a  design  environment  since  very  often  the  de¬ 
signer  has  a  particular  structure  in  mind  when  designing  hardware.  This 
partial  structure  should  be  captured  by  the  language,  and  reflected  in 
the  results  of  s]mthesis.  A  design  often  requires  interfacing  to  an  existing 
hardware  unit,  such  as  an  ALU  or  incrementer.  The  ability  to  interface 
with  external  structure  is  of  utmost  importance  in  automated  synthesis. 

Many  synthesis  systems  and  hardware  description  languages  support  only 
a  specific  design  style,  either  pure  structure  or  pure  behavior.  We  believe 
a  more  effective  approach  to  design  is  to  use  a  flexible  underlying  language 
that  captures  the  essence  of  the  design  &om  the  designer,  whether  that 
essence  be  behavioral  or  structural. 

2.  Supports  simulation. 

The  language  should  support  simulation  in  order  to  ascertain  the  correct¬ 
ness  of  a  given  description.  As  designs  become  bigger  and  more  complex, 
it  becomes  more  important  to  be  able  to  simulate  at  all  levels  of  synthesis, 
from  behavioral  to  structural  to  logic  to  gate  level. 

3.  Simple  to  learn  and  use. 

The  language  is  a  tool  that  the  designer  uses  to  capture  and  transform 
abstract  ideas  into  complete  designs.  The  tool  must  therefore  be  simple 
to  learn  and  easy  to  use.  Specifically,  the  language  should  contain  the 
most  basic  constructs  that  are  needed  to  describe  a  design.  Details  such 
as  timing  and  delay  should  be  left  out  of  the  language. 

HardwareC  attempts  to  satisfy  the  requirements  stated  above.  As  its  name 
implies,  it  is  based  somewhat  on  the  C  programming  language.  However,  several 
enhancements  are  made  to  increase  the  expressive  power  of  the  language,  as 
well  as  to  facilitate  hardware  description.  The  major  features  of  HardwareC  are 
described  below. 

•  Notions  of  concurrent  processes  and  message  passing, 

•  Templates  that  allow  a  single  description  for  a  group  of  similar  behavior 
(polymorphism).  For  example,  an  adder  template  describes  all  adders  of 
any  given  size, 


•  Instantiation  of  procedures,  similar  to  instantiating  objects  in  object  ori¬ 
ented  languages,  and 

•  Explicit  Input/Output  commands  that  access  the  ports  of  a  given  model. 

HardwareC  can  be  linked  to  the  THOR  simulation  environment,  which  is 
also  based  on  a  C-iike  simulation  language  [4]. 

3  Modeling  Hardware  Behavior 

Hardware  behavior  is  modeled  as  a  collection  of  concurrent  and  interacting  pro¬ 
cesses.  Each  process  consists  of  a  hierarchy  of  procedures,  and  the  processes 
interact  and  synchronize  with  each  other  through  the  use  of  inter-process  com¬ 
munication  mechanisms.  This  model  is  appropriate  since  hardware  modules  are 
allocated  resources  which  continuously  operate  on  a  time  varying  set  of  inputs. 
A  process  upon  completion  will  automatically  restart  execution  with  a  new  set 
of  inputs. 

The  concept  of  processes  a;,d  inter-process  communication  is  powerful  for 
both  hardware  and  software  models.  In  both  domains,  it  allows  the  designer  to: 

1.  Specify  the  parallelism  between  interacting  modules  at  a  high  level,  and 

2.  Isolate  the  communication  and  synchronization  points  between  the  pro¬ 
cesses  in  an  explicit  manner. 

As  an  illustration  of  the  use  of  processes  and  inter-process  communication, 
consider  the  Intel  82S1  UART  (Figure  1).  The  UART  is  modeled  as  four  concur¬ 
rently  executing  processes.  The  main  process  accepts  commands  from  the  micro¬ 
processor  and  coordinates  the  execution  of  the  other  processes.  The  transmitter 
process  writes  data  out  on  the  serial  interface,  and  the  two  receiver  processes, 
synckronous.receiver  and  asynckronous.receiver,  reads  data  from  the  serial  in¬ 
terface.  Note  that  the  execution  of  each  process  is  independent  with  respect  to 
each  other,  and  is  synchronized  through  the  use  of  inter-process  communication. 
Inter- process  communication  is  discussed  further  in  Section  12. 

HardwareC  is  a  hardware  description  language  for  synchronous  digital  cir¬ 
cuits.  This  is  a  reflection  of  the  hardware  model  assumed  by  the  HERCULES 
Synthesis  system.  Therefore,  there  b  the  notion  of  a  control  state  that  is  some¬ 
times  used  to  describe  the  language.  A  control  state  b  defined  as  an  interval  of 
time  that  corresponds  to  a  system  clock  cycle  in  a  synchronous  system.  When 
a  particular  operation  is  said  to  take  one  or  more  states,  it  means  that  the  ex¬ 
ecution  of  the  operation  requires  one  or  more  clock  cycles  to  complete  before 
other  operations  that  depend  on  it  can  begin. 

The  HardwareC  language  is  described  in  the  sections  that  follow. 
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Figure  1:  Hardware  model  for  Intel  8251  UART 


4  Program  Structure 

In  SardwareC,  there  are  two  fundamental  functional  abstraction  mechanisms 
>  process  and  procedure.  A  process  consists  of  a  hierarchy  of  procedures,  and 
executes  concurrently  and  independently  with  respect  to  the  other  processes  in 
the  system.  Similarly,  a  procedure  is  also  a  hierarchy  of  procedures.  However, 
a  procedure  executes  whenever  it  is  called  by  another  procedure  or  process.^ 
The  transfer  of  data  to  and  from  a  process  is  accomplished  through  the 
use  of  either  parameters  to  the  process  or  through  message  passing  mechanisms 
(Section  12).  The  transfer  of  data  to  and  from  a  procedure,  on  the  other  hand,  is 
accomplbhed  solely  through  the  use  of  parameters  to  the  procedure  (Section  11). 
A  procedure  can  neither  return  a  value  as  the  result  of  its  invocation,  nor  use 
message  passing  to  communicate  with  other  procedures.  The  major  differences 
between  a  process  and  a  procedure  are  summarised  below. 

•  Process.  A  process  continuously  operates  on  a  time-varying  set  of  input 
data.  Upon  completion  of  the  last  statement  in  its  body,  a  process  will 
restart  its  execution,  operating  on  a  possibly  different  set  of  inputs.  An 
example  of  the  definition  of  process  procA  is  shown  below.  Note  the  use 
of  the  keyword  process  which  prefixes  the  name  of  the  process. 

process  pn>cA(  a,  i,  c  ) 
in  boolean  a; 
out  boolean  b\ 

^  No  recursive  procediires  ore  allowed 
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{ 

} 


inout  boolean  c[2]; 
/•  body  of  process  •/ 


•  Procedure.  A  procedure  can  either  be  combinational  or  sequential,  de¬ 
pending  on  whether  the  procedure  requires  any  control  states  to  execute. 
A  sequential  procedure  begins  execution  whenever  it  is  called  by  another 
procedure.  Upon  completion  of  execution,  a  procedure  places  valid  data  on 
its  output  ports,  and  returns  control  to  the  calling  routine.  For  combina¬ 
tional  procedures,  execution  involves  propagating  the  input  data  through 
a  network  of  combinational  operations.  An  example  of  the  deftnition  of 
procedure  procB  is  shown  below. 

procB{  z,  y,  z) 

in  boolean  z; 
out  boolean  y, 
inout  boolean  42]; 

{ 

/»  body  of  procedure  •/ 

} 


A  procedure  cannot  be  defined  within  the  body  of  another  procedure. 
This  restriction  follows  the  C  language,  which  disallows  nested  procedural 
definitions.  The  resulting  flattening  of  the  procedural  definition  is  appro¬ 
priate  since  for  hardware  description,  it  is  more  convenient  and  secure  to 
identify  explicitly  all  inputs  and  outputs  to  a  given  procedure.  A  proce¬ 
dure  defined  within  the  scope  of  another  aUows  access  to  all  variables  that 
are  defined  within  the  scope  of  its  definition.  As  a  result,  a  procedure's 
boundary  is  not  well  defined  if  nested  procedural  definitions  are  allowed. 

Nested  procedural  definition  is  different  from  nested  procedural  invoca¬ 
tion,  the  latter  of  which  is  both  permitted  and  encouraged.  For  example, 


/• 

•  invalid  procedure 

*  definition 

•/ 


/* 

•  valid  procedure 

•  definition 

•/ 


procAfa,  b) 


validproc(x,  y) 
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invalidprocCx,  y) 

•C 


< 


} 

invalidproc(  — ) 


} 


y 


procA(a,  b) 

{ 

validproc (  ...  ) ; 

} 


4.1  Statement  Block 

Statement  block,  more  commonly  known  as  compound  statement,  is  used  to 
group  variable  declarations  and  statements  together  so  that  they  ate  syntac¬ 
tically  equivalent  to  a  single  statement.  A  statement  can  either  be  a  variable 
assignment,  an  if-then-else  statement,  a  switch  statement,  a  while  statement, 
a  for  statement,  an  input/output  statement,  a  message  passing  primitive,  or  a 
block.  Semi-colons  are  used  as  terminators  to  statements.  A  semicolon  by  itself 
represents  a  null  statement. 

HardwareC  supports  two  types  of  statement  blocks  -  parallelizahle  blocks 
and  serial  blocks.  Parallelizable  blocks  are  encapsulated  using  curly  braces  ( { 
and  }),  whereas  serial  blocks  are  encapsulated  using  square  brackets  ([  and  ]). 
The  differences  between  the  two  types  are: 

•  Parallelizable  Block  {  }-  The  statements  within  a  parallelizable  block  can 
all  execute  in  parallel,  subject  to  the  data  dependencies  that  exist  between 
the  statements.  For  example, 

{ 

vanable.declaraiions', 

statement  1; 

Statements-, 

} 


means  that  statementl  can  be  executed  concurrently  with  statements.  The 
degree  of  parallelism  is  determined  by  the  synthesis  system. 

•  Serial  Block  [  ]  -  The  statements  within  a  serial  block  are  guaranteed  to 
execute  in  serial  order,  starting  from  the  first  statement  in  the  block.  For 
example,  statementl  will  always  execute  before  statements,  regardless  of 
their  data  dependencies. 
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variabU^declarations; 


] 


siatementr, 

staiement2; 


Serial  block  allows  the  designer  the  ability  to  specify  control  dependencies 
between  otherwise  data  independent  statements. 

A  description  written  using  only  serial  blocks  is  always  guaranteed  to  be 
correct  -  that  is,  the  control  dependencies  between  the  statements  are  fully 
described.  However,  the  description  may  not  be  efficient,  since  inter-statement 
parallelism  is  not  exploited.  In  order  to  specify  such  parallelism,  the  designer 
should  use  whenever  possible  parallelisable  blocks  ({  }}  in  describing  hardware. 

4.2  Parameter  Classes 

The  parameters  to  processes  and  procedures  are  categorized  into  three  differ¬ 
ent  classes:  in,  out,  and  inout.  Input  (in)  parameters  can  only  be  referenced 
within  the  body  of  a  routine;  assignments  to  input  parameters  are  iUegal.  Out¬ 
put  (out)  parameters  can  be  modified  within  the  body  of  a  routine;  references 
to  output  parameters  are  illegal.  Input/output  (inout)  parameters  are  bidirec¬ 
tional  lines  that  can  be  either  referenced  or  assigned.  The  access  protocol  to 
this  bidirectional  line  is  left  to  the  designer,  and  specified  as  part  of  the  high- 
level  description.  Note  that  an  inout  parameter  is  not  simply  data  that  will 
both  be  read  and  modified  in  the  routine.  It  is  reserved  for  the  description  of 
bidirectional  lines. 

For  example.  Busy  is  an  in  parameter  that  controls  the  access  to  an  inout 
parameter  Data.  A  llZero  is  an  output  parameter  that  returns  a  flag  on  whether 
Data  is  all  zero. 

process  test{  Busy,  Data,  AllZero  ) 
in  boolean  Busy, 
inout  boolean  Data[8]; 
out  boolean  AllZero; 

[ 

while  (  Busy  ) 

I 

/•  write  to  Data  */ 

Data  =  newdata; 
write  Data-, 

AllZero  =  (Data  ==  0); 
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] 


Notice  the  use  of  the  serial  block  ([  ])  to  ensure  that  the  write  to  Data  occurs 
after  the  busy  waiting  while  loop,  which  does  not  have  any  data  dependencies 
with  respect  to  the  write. 

4.3  Declare  Before  Use 

Whenever  a  procedure  is  called,  the  arguments  to  the  invocation  are  checked 
for  both  compatibility  in  the  variable  sise  and  type,  as  well  as  for  compatibility 
in  the  parameter  classification.  For  instance,  an  input  parameter  cannot  be 
used  as  the  argument  to  a  procedure  call  that  requires  an  output  parameter. 
Similarly,  an  output  parameter  cannot  be  used  as  the  argument  to  a  procedure 
call  that  requires  an  input  parameter.  This  compile  time  consistency  checking 
improves  the  security  of  the  language. 

In  order  to  provide  this  information  to  the  parser,  it  is  necessary  to  declart 
a  procedure  before  it  can  be  called.  The  declaration  of  a  procedure  involves 
specifying: 

1.  Name  of  the  procedure  -  can  be  any  alphanumeric  string  beginiting  with 
a  character. 

2.  Number  and  order  of  parameters  -  only  Boolean  parameters  are  allowed. 

3.  Sizes  of  the  parameters  -  the  size  of  a  parameter  can  be  specified  in  terms 
of  a  constant,  or  an  expression  that  evaluates  to  a  constant. 

4.  Classes  of  the  parameters  -  in,  out,  or  inout. 

An  example  of  the  declaration  for  a  procedure  is  shown  below. 

«  define  MAX  4 

declare  example (  a,  b,  c  ) 
in  boolean  a; 
out  boolean  b  CHAX] ; 
inout  boolean  c[NAX-^l]: 

The  actual  names  of  the  parameters  are  irrelevant;  they  are  used  only  for 
the  purpose  of  specifying  the  classes  and  sizes  of  the  corresponding  parameters. 
Another  example  is  shown  below. 

declare  sumf  z,  y,  z  ) 
in  boolean  z; 
out  boolean  y[2]; 
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inont  boolaan  z, 


foo(  ...  ) 

{ 

/• ...  •/ 
jttm(  a.  b,  c  ); 
/.  ...  •/ 


If  the  declaration  of  sum  is  not  supplied,  then  the  subsequent  call  in  foo 
will  be  invalid.  Similarly,  for  inter*process  communication  through  message 
passing,  it  is  necessary  to  predeclare  a  particular  process  before  sending  or 
receiving  messages  from  it.  The  declaration  for  a  process  is  exactly  similar  to 
the  declaration  for  a  procedure,  with  the  sole  exception  of  the  keyword  process 
that  prefixes  the  name.  For  example,  the  declaration  for  a  process  named  foobar 
is  as  follows. 

declare  process  foohar{  a,  b,  c  ) 
in  boolean  a[3]; 
out  boolean  6(4]; 
inout  boolean  c[2]; 


5  Data  in  HardwareC 

There  are  two  types  of  data  entities  in  the  language  -  constants  and  variables. 
They  are  described  in  the  following  sections. 

5.1  Constants 

There  are  two  types  of  constants  in  the  language  -  integer  constants  and  kez- 
adectmal  constants.  Integer  constants  are  positive  numbers  described  in  the 
decimal  notation.  For  example,  5  and  223  are  integer  constants.  Hexadecimal 
constants  are  numbers  described  in  the  hexadecimal  notation.  They  are  pre¬ 
fixed  by  Ox,  followed  by  a  string  of  hexadecimal  digits  {  0  -  9,  a,  b.  c,  d.  e.  f 
}.  For  example,  Ox/  represents  15,  and  0x10  represents  16.  Binary  constants 
are  subsets  of  hexadecimal  constants,  where  1  is  represented  as  0x1,  and  0  is 
represented  as  0x0. 

Negative  constants  are  not  represented  in  the  language.  This  restriction 
stems  from  the  independence  of  HardwareC  to  a  particular  style  of  complemen¬ 
tation.  Therefore,  if  the  designer  wishes  to  specify  -3  in  one's  complement 
notation,  then  he  should  specify  the  bit-wise  representation  of  the  value  using 
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hexadecimal  constants.  Fot  an  8-bit  number  in  one's  complement  notation.  -3 
is  represented  as  Oz/8. 


5.2  Variables 

There  are  two  variable  types  in  the  language  -  Boolean  ruid  integer.  Boolean 
variables  are  mapped  to  wires  or  registers  in  the  final  hardware,  whereas  integer 
variables  are  provided  for  the  convenience  of  the  description,  and  will  be  resolved 
at  compile  time  during  behavioral  synthesis. 

A  variable  may  be  declared  within  any  block  ({  }  or  [  ])  of  any  arbitrary 
nesting.  The  semantic  follows  that  of  block  structured  languages,  where  a  vari¬ 
able  is  visible  only  within  the  scope  of  its  definition.  A  variable  with  the  same 
name  at  a  deeper  nesting  block  level  will  override  any  current  definition  of  the 
variable. 

For  instance,  all  declarations  in  the  following  example  are  valid. 

{ 

int  i; 

boolean  x: 

{ 

int  i:  /«  new  integer  «/ 
boolean  x,  y; 

} 

/ «  y  is  not  defined  here  «/ 

} 


No  global  variables  are  allowed  in  HardwareC.  This  restriction  is  due  to  the 
fact  that  global  variables  allow  side  effects  that  are  not  explicitly  identified. 
This  is  undesirable  from  the  standpoint  of  security,  verifiability,  and  program 
readability.  If  some  data  must  be  shared  between  two  routines,  then  the  data 
should  be  explicitly  specified  as  common  parameters  to  the  two  routines. 

Integer  Integer  variables  can  only  be  scalar  quantities.  Integer  variables  may 
be  used  in  any  arithmetic.  Boolean,  and  relational  expressions.  They  can  also 
be  used  as  indices  to  constant  iteration  loops  (for  loop),  and  as  indices  for 
accessing  components  of  Boolean  vectors  and  matrices.  The  following  example 
demonstrates  the  use  of  integer  variables  and  expressions  in  accessing  compo¬ 
nents  of  a  Boolean  vector. 

/• 

•  snaps  the  tno  nibbles  in  "a"  to  "b" 

•  / 
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ssap(a,  b) 

in  boolaan  aC8] : 
out  booloan  b[8] ; 

int  i,  j,  k; 

k  =  3; 

/*  copies  LSB  nibble  to  b  •/ 
for  1  s  0  to  k  do 

b[  i+4:i+4  ]  =  »[  i:i  ]; 

/*  does  exactly  the  sane  thing  •/ 
i  *  0; 
j  *  3 ; 

bC  it'4:  j-*-4  ]  =  aC  i:  j  ] ; 

/*  copies  MSB  nibble  to  b  •/ 
bC  i: j  ]  =  aC  i+4: j+4  ] ; 

erite  b; 

> 

The  exact  syntax  on  accessing  components  of  a  Boolean  vector  is  discussed 
in  the  next  section.  The  example  below  shows  the  use  of  integer  expressions 
and  values  in  control  structures. 

int  i; 

boolean  vec [24] ; 

for  i  =  0  to  7  do  { 
switch  (i)  { 

case  0: 

vec[  3«i:3*i+2  ]  =  0x7;  /•  binary  111  •/ 

break; 
default : 

vec[  3»i:3»i+2  ]  =  i; 
break; 

} 

} 

/*  vec  should  have  the  following  value: 

111  110  101  100  oil  010  001  111 
MSB  LSB 

•/ 
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Boolean  A  Boolean  variable  represents  one  or  more  signals,  where  each  bit  of 
the  variable  corresponds  to  a  stpnaithat  can  be  either  0  or  1.  Boolean  variables 
can  be  scalar,  vector,  or  matrix.  For  example,  the  following  declarations  are  all 
valid  Boolean  variables.  In  particular,  a  is  a  scalar,  b  is  a  vector  of  five  elements 
starting  from  index  0,  and  c  is  a  matrix  of  25  elements,  with  the  tows  starting 
&om  0  to  4,  and  columns  starting  from  0  to  4. 

boolean  a;  /*  scalar  */ 

boolean  bCS] ;  /•  vector  */ 

boolean  c  CS] CS] ;  /*  matrix  */ 

In  Boolean  vectors,  specifying  the  variable  name  without  brackets,  or  with 
empty  brackets,  represent  the  entire  vector.  For  example,  b  and  b  []  are  equiv¬ 
alent  to  bC0:4].  Columns  of  a  Boolean  matrix  can  be  accessed  similarly.  For 
example,  c[2]  and  c[2]  □  are  equivalent  to  c[2]  [0:4].  Since  assignments  to 
matrices  are  not  permitted,  a  reference  to  c  will  automatically  be  converted  to 
c  [O]  [0:4],  the  first  row  of  the  matrix. 

For  Boolean  vectors  and  matrices,  it  is  also  possible  to  access  a  subrange  of 
values.  This  is  specified  by  the  colon  (;)  notation.  For  example,  b[2:3]  repre¬ 
sents  a  vector  of  two  values  that  corresponds  to  the  third  and  fourth  element 
of  b.  The  most  significant  bit  (MSB)  is  always  the  higher  index,  with  the  least 
significant  bit  (LSB)  being  the  smaller  index. 

Integer  variables  and  expressions  can  be  used  in  variable  declarations  to 
specify  the  dimensions  of  the  variable,  ot  they  can  be  used  to  access  components 
and  subranges  of  Boolean  variables.  For  example, 

int  i; 

i  =  3; 

c[i] [i:i+l]  =  b[0:l] ; 

boolean  qfi-M] ;  /•  q  has  4  elements  •/ 

} 

Boolean  variables  are  further  classified  as  local,  static,  and  register. 

•  boolean  -  Local  Boolean  variables  are  the  default.  A  local  boolean  is 
initialized  to  zero,  and  its  value  is  not  saved  across  procedure  invocations. 
For  example, 

boolean  flag; 

boolean  vectorflag[2] ,  matrixf lag[2]  [3]  ; 

e  static  -  Static  Boolean  variables  are  similar  to  local  Boolean  variables, 
with  the  semantic  difference  that  their  values  are  retained  across  proce¬ 
dural  invocations.  For  example. 
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static  iiitanial_statsC2]  : 


Static  variables  will  always  be  implemented  with  storage  elements  such  as 
registers. 

•  register  -  Register  Boolean  variables  are  architected  registers  that  are 
specified  by  the  designer.  Similar  to  static  variables,  they  also  retain 
their  values  across  procedural  invocations.  Every  assignment  to  a  register 
variable  immediately  loads  the  corresponding  register  with  a  new  value. 
For  example, 

register  status [8] ; 

The  difference  between  register  and  static  variables  is  in  how  assign* 
ments  are  handled,  which  is  discussed  next. 

Assignments  to  boolean  and  static  variables  are  resolved  during  behavioral 
synthesis,  and  hence  do  not  require  any  control  states  for  run>time  execution. 
In  contrast,  each  assignment  to  a  register  variable  corresponds  to  the  loading 
of  the  register  with  a  new  value,  and  hence  requires  a  control  state  at  run-time. 

To  demonstrate  the  differences  between  static  and  register  variables,  consider 
the  two  examples  below.  In  procedure  too,  each  assignment  to  the  static 
variable  c  will  not  consume  a  control  state  at  run-time.  This  is  due  to  the  fact 
that  the  assignment  only  changes  subsequent  references  to  c.  and  hence  does 
not  imply  loading  the  register  that  implements  c  with  a  new  value. 

JooO 

{ 

static  c; 

c  =  1;  /•  change  reference  only  •/ 

c  s  0;  /•  change  reference  only  •/ 

c  *  1;  /•  change  reference  only  •/ 

c  =  0;  /*  last  value  of  c  is  0  •/ 

) 

Similarly,  the  register  variable  c  in  procedure  bar  also  has  a  final  vidue 
of  0.  The  difference  is  that  during  the  execution  of  bar,  the  register  is  loaded 
with  4  values,  corresponding  to  each  assignment  to  the  variable.  Therefore,  the 
procedure  requires  four  control  states  to  execute. 

barO 

{ 

register  c; 
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c  »  1;  /•  register  has  1  •/ 

c  ®  0;  /•  register  has  0  •/ 

c  s  1;  /«  register  has  1  again  •/ 

c  s  0:  /•  last  value  of  c  is  0  •/ 

> 

In  terms  of  port  behavior,  static  and  register  variables  perform  the  same 
action  -  retain  values  across  invocations.  Architected  registers  allow  the  designer 
explicit  control  over  the  contents  of  the  register.  They  are  useful  for  testability 
purposes  where  the  designer  vrishes  to  check  the  contents  of  a  particular  register 
during  execution.  For  example,  architected  registers  are  often  used  tis  a  status 
register  in  a  processor  description. 

5.3  Variable  Declaration 

The  dimension  of  a  Boolean  variable  may  be  specified  as  either  a  constant,  an 
integer  variable,  or  an  integer  expression.  For  instance,  consider  the  declarations 
for  Boolean  variables  a  and  b. 

{ 

int  i; 

i  “  3; 

boolean  afi};  /•  a  has  3  elenents  •/ 

} 

i  =  8; 

{ 

boolean  bCi-^3] ;  /•  b  has  11  elements  */ 

> 

> 

In  fact,  even  the  dimensions  of  the  parameters  can  be  specified  as  arbitrary 
integer  expressions.  The  delayed  binding  of  variable  dimension  to  variable  def¬ 
inition  greatly  increases  the  expressiveness  of  the  language,  and  improves  the 
flexibility  and  adaptability  of  an  input  description.  An  iUustration  of  the  use  of 
integer  expressions  in  parameter  declaration  is  shown  below. 


t  define  Hkl  8 
declare  fooCa,  b) 

in  boolean  aCNAX-*-!] /•  9  elenents  •/ 
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out  boolean  bClUX-^2];  /•  10  elements  «/ 


Note  that  the  integer  expressions  (MAX-^1)  and  (MAX-^2)  are  used  to  declare 
the  dimensions  of  the  parameters. 

6  Control  Flow  Constructs 

HardwareC  supports  a  single-in,  single-out  control  flow,  similar  to  the  Pascal 
prograituning  language.  This  implies  that  no  gotos  and  returns  are  allowed  in 
the  language.  Such  restriction  is  appropriate  since  by  supporting  a  single-in, 
single-out  control  flow,  the  semantics  of  the  language  is  made  simpler,  which 
greatly  aids  in  the  correctness  veriftcation  of  programs.  The  four  major  control 
flow  constructs  are  if,  switch,  for,  and  while-,  they  are  described  below. 

•  »/ 

selects  among  two  alternatives,  depending  on  whether  the  conditional  ex¬ 
pression  evaluates  to  TRUE  or  FALSE,  non-xero  or  zero,  respectively.  The 
conditional  expression  can  be  any  arithmetic,  Boolean,  and  relational  ex¬ 
pression  that  involves  both  integer  and  Boolean  variables.  The  else  pan 
may  be  unspecified.  For  example. 

iX  (  !  b  *  chipsalact  ) 

a  *  0;  /■  any  statement  •/ 

else 

a  =  1;  /•  any  statement  ■/ 


•  switch 

selects  among  one  or  more  alternatives,  depending  on  the  value  of  the 
switch  conditional  expression.  The  individual  cases  in  the  switch  state¬ 
ment  may  be  cascaded,  and  are  delimited  through  the  use  of  break  state¬ 
ments. 

snitch  (  <snitch  expT>  )  { 
case  nuBl: 

<atatement> 
case  num2: 
case  num3: 

<statement> 

break; 

default : 
break; 

} 


15 


br«ak  statements  aie  illegal  in  any  other  contexts,  such  as  for  premature 
exits  from  while  loops. 

•  for 

is  a  constant  bound  iteration  on  a  given  integer  variable.  The  exact  syntax 
is  as  follows, 

for  <int  var>  *  exprl  {toldounto}  expr2  [atap  exprS] 
do  <statament> 

where  exprl,  expt2,  and  expt3  can  be  any  constant  or  integer  expression. 
The  step  clause  is  optional,  and  has  a  default  of  one. 

•  while 

is  a  data  dependent  iteration  on  a  given  Boolean  expression.  The  syntax 
of  the  while  loop  is  as  follows. 

while  (  loop.expr  ) 

<statenent> 

loop.expr  can  be  any  integer,  relational,  or  Boolean  expression. 

There  are  only  two  types  of  iterative  loop  constructs  in  HardwareC  -  for 
loops  and  while  loops.  For  loops  are  deterministic  iteration  loops,  whose  bounds 
are  known  at  compile  time.  A  while  loop  is  a  non-deterministic  iteration  whose 
exit  condition  can  be  data  dependent,  and  hence  is  in  general  unknown  at  com¬ 
pile  time.  Whereas  there  are  many  variants  of  data-dependent  loops,  such  as 
do-whil«  and  repeat-until,  they  can  all  be  written  in  terms  of  while  loops. 
Including  the  many  variants  of  data-dependent  loops  does  not  increase  the  ex¬ 
pressive  power  of  the  language.  Therefore,  for  reasons  of  simplicity,  HardwareC 
supports  only  one  style  of  data-dependent  loops  -  the  while  loop. 

7  Assignments 

When  a  program  references  a  particular  variable  at  different  locations  in  the 
code,  it  may  reference  different  values,  depending  on  whether  the  variable  has 
been  re-assigned  between  the  references.  The  value  of  a  variable  is  defined  to 
be  the  data  most  recently  assigned  to  it.  ^  An  assignment  to  a  variable  modifies 
the  value  of  the  variable. 

Both  Boolean  and  integer  variables,  as  well  as  inout  and  out  parameters, 
can  be  assigned.  Note  that  an  assignment  is  not  an  expression  that  returns  a 

is  defined  to  be  the  results  of  procedure  call,  binary  and  unary  operators,  or  message 

passing. 
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value.  For  example,  a  =  a  +  1  does  not  return  the  new  value  of  a,  which  is  in 
contrast  to  the  C  programming  language. 

The  semantics  of  assignment  to  different  types  of  variables  are  described 
below. 

•  out  or  inout  parameters. 

Assignments  to  an  output  or  input/output  parameter  will  update  the  value 
of  the  port.  The  actual  reflection  of  the  port  values  to  externally  visible 
signals  is  performed  explicitly  through  the  use  of  input/output  commands, 
discussed  in  Section  11. 

•  int ,  boolean,  or  static  variables. 

Assignments  to  these  variables  will  be  resolved  and  removed  during  be¬ 
havioral  synthesis.  Therefore,  the  assignments  serve  only  to  update  the 
value  of  the  variable  for  subsequent  references,  and  do  not  consume  any 
control  states  at  run-time.  Only  constants  or  integer  expressions  can  be 
assigned  to  integer  variables.  There  is  no  restriction  on  the  values  that 
can  be  assigned  to  Boolean  variables. 

•  register  variables. 

An  assignment  to  an  architected  register  loads  the  register  with  a  new 
value.  Therefore,  every  assignment  requires  a  control  state  for  execution 
at  run-time. 

8  Templates 

Very  often  two  descriptions  differ  in  only  very  restricted  ways.  For  example, 
they  are  the  same  with  the  sole  exception  that  the  variable  sizes  are  different, 
as  illustrated  below  for  a  four-bit  and  a  five-bit  adder. 

/• 

•  Four-Bit  adder 
•/ 

adder4(a,  b,  c,  cin,  cout) 

in  boolean  a[4],  b[4] ,  cin; 
out  boolean  c [4] ,  cout ; 

{ 

/•  4  bits  add  •/ 

> 

/• 

•  Five-Bit  adder 
•/ 
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adderSCa,  b,  c.  cin,  cout) 

in  boolaan  aCS] ,  b[S] ,  cin; 
out  boolaan  c  Cs] ,  cout ; 

/*  saaa  as  above,  but  for  5  bits  •/ 

> 


It  is  much  simpler  and  expressive  if  only  one  description  is  given  for  the  adder 
function  which  takes  an  argument  specifying  the  sixe  of  the  operation.  This 
approach  offers  the  advantages  of  (1)  consistency  of  descriptions,  (2)  economy  of 
code,  which  decreases  design  time,  and  (3)  reusability  of  code  (polymorphism). 

In  HardwareC,  the  mechanism  which  supports  parameterized  descriptions  is 
a  template.  A  template  can  either  be  used  to  generate  a  procedure  or  a  process. 
Templates  are  similar  to  generic  packages  in  ADA,  or  generic  classes  in  several 
object  oriented  languages.  A  template  takes  one  or  more  integer  arguments 
as  parameters,  and  given  a  particular  mapping  of  integer  values  to  the  integer 
parameters,  a  corresponding  instance  can  be  obtained.  A  good  analogy  can  be 
made  between  templates  and  module  generation;  in  fact,  a  template  is  a  form 
of  high-level  module  generation.  The  exact  syntax  of  templates  for  procedures 
and  processes  is  given  below. 

•  Procedure  Template  definition: 

tenplate  <pTocedure_nane>  (  <paraneters>  ) 

uith  (  <integer_paraneters>  ) 

<paraaet«r  declarations> 

{ 

<body> 

} 

•  Process  Template  definition: 

template  process  <procedure_nane>  (  <parameters>  ) 

with  (  <integer_paraaeters>  ) 

<parameter  declaratioRS> 

{ 

<body> 

} 

The  keyword  tenplate  prefixes  the  name  of  the  template,  and  the  keyword 
vith  separates  the  Boolean  parameters  from  the  integer  parameters.  The  in¬ 
teger-parameters  are  the  names  of  the  integer  parameters,  and  are  separated 
by  commas  (,)  if  more  than  one  is  present.  These  integer  parameters  can  be 
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used  in  both  parametet  declaration  and  the  body  of  the  template  as  integer 
constants.  Specifically,  assignment  to  an  integer  parameter  is  not  allowed. 

Let  us  consider  the  description  of  a  template  for  the  ripple-carry  adder  func¬ 
tion. 


/• 

•  ripple  carry  adder 
•/ 

teiqtlate  adder (a,  b,  c,  cin,  cout)  with  (size) 
in  boolean  a [size] .  bCsize] .  cin; 
in  boolean  c [size] .  cout ; 
i 

int  i,  j; 
boolean  temp; 

tesq)  =  cin; 

j  =  size  -1; 

for  i  =  0  to  j  do  < 

cCi:i]  =  a[i:i]  tor  b[i:i]  zor  tenp; 
temp  s  aCi:i]  ft  b[i:i]  I 

tenp  ft  (aCi:i]  I  b[i:i]); 

} 

cout  s  tenp; 
write  c,  cout; 

} 

Templates  can  be  used  in  two  ways,  corresponding  to  the  environment  level 
and  the  language  level. 

1.  Environment  Level  -  The  HERCULES  Synthesis  system  can  create  any 
number  of  instances  of  a  given  template.  This  is  useful  for  example  in 
generating  library  units  such  as  adders  or  incrementers. 

2.  Language  Level  -  Within  the  description,  the  designer  can  make  refer¬ 
ences  to  particular  instances  of  a  template  through  instantiating  templates. 
Template  instantiation  is  described  next. 


9  Instances 

HardwareC  supports  explicit  instantiation  of  procedures  and  procedure  tem¬ 
plates  in  the  description.  A  instance  of  a  procedure  represents  an  object  that 
encapsulates  both  behavior  and  state.  In  a  similar  manner,  a  Boolean  vari¬ 
able  is  also  an  object  whose  behavior  is  specified  by  the  language  in  terms  of 
the  semantics  of  accessing  and  modifying  the  variable.  Instances  can  therefore 
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be  tieated  as  instance  vartables  that  aie  declaied  and  used  in  the  scope  of  its 
definition.  The  syntax  of  procedure  instantiation  is  described  below. 

instance  <pToc«diir«_naflM>  instl.  in8t2 . instn; 

The  keyword  instance  prefixes  the  name  of  the  procedure  ,  followed  by  the 
names  of  the  instances  to  be  created,  separated  by  commas.  If  a  template  is 
instantiated,  the  syntax  is  described  as  follows. 

instance  <tenplate_naae> (  <integer.aTg>  }  tl,...,tn,‘ 

the  arguments  to  the  integer  parameters  should  be  specified,  separated  by 
commas.  The  integer  arguments  must  be  constants,  and  cannot  be  any  variables 
or  expressions.  Note  that  the  scoping  rules  for  variable  visibility  also  apply  to 
instances.  Consider  the  example  below,  where  counter  is  a  procedure  that 
increments  an  internal  variable  each  time  it  is  called. 

■C 

instance  counter  a; 

instance  adder(4}  o4;  /•  4  bit  adder  «/ 

instance  counter  a,  b; 
a( . . . ) ;  /■  nes  counter  •/ 

/*  can  access  o4  also  */ 

} 

a(...):  /•  old  counter  •/ 

/*  b  is  undefined  here  •/ 

} 

The  instance  a  of  counter  is  different  for  each  different  nesting  of  the  block. 

9.1  Calling  a  Procedure 

A  procedure  may  be  called  by  another  process  or  procedure.  This  is  accom¬ 
plished  by  specifying  the  name  of  the  procedure  to  be  called,  along  with  the 
arguments  to  the  procedure  separated  by  commas  and  enclosed  in  parentheses. 
A  procedure  must  be  declared  or  defined  before  it  can  be  called,  otherwise  the 
call  will  result  in  an  error. 

Valid  arguments  to  a  procedure  call  depend  on  the  particular  class  of  the 
corresponding  parameters.  Specifically, 
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•  In  Parameter  -  All  in  parameters,  inout  parameters,  local  boolean, 
static,  and  register  variables  and  expressions  are  allowed  to  be  used 
as  arguments  in  the  procedure  call. 

•  Out  Parameter  -  All  out  parameters,  inout  parameters,  local  boolean 
variables,  and  static  variables  are  allowed.  No  register  variables  are 
allowed. 

•  Inout  Parameter  -  Only  inout  parameters  are  allowed. 

There  are  two  types  of  procedure  calls  -  generic  or  instantiated  calls.  A 
generic  call  is  a  call  made  to  a  given  procedure  type.  The  particular  instance  of 
the  procedure  type  that  is  used  to  implement  the  call  is  not  specified.  To  invoke 
a  particular  instance  of  a  procedure,  the  name  of  the  instance  simply  replaces 
the  name  of  the  procedure  in  a  procedure  call.  This  style  of  procedure  call  is 
called  an  instantiated  procedure  call.  For  example, 

{ 

instance  counter  x; 

counter( . . .) ;  /■  generic  call  */ 

x(...);  /•  instantiated  call  •/ 

counter( . . . ) ;  /•  generic  call  •/ 

x(...};  /■  instantiated  call  •/ 

} 

All  the  calls  to  x  will  invoke  the  same  instance.  However,  if  a  procedure 
is  invoked  without  specifying  the  instance  (generic  procedure  calls),  then  the 
synthesis  system  is  free  to  determine  whether  the  call  can  be  shared  with  other 
generic  calls,  or  whether  to  allocate  an  instance  to  the  call. 

9.2  Advantages  of  Instantiating  Procedures 

There  are  several  advantages  in  supporting  both  generic  and  instantiated  pro¬ 
cedure  calls.  They  are  briefly  described  below. 

1.  Resolves  Ambiguity  in  the  behavior.  The  designer  can  completely  describe 
the  behavior  that  is  intended  without  relying  on  hidden  assumptions. 

2.  Access  to  both  State  and  Behavior.  The  designer  can  access  not  only 
behavior  through  procedure  calls,  but  also  internal  state  information  as 
well. 

3.  Supports  Spectrum  of  Design  descriptions.  Depending  on  the  style  of  the 
designer,  hardware  can  be  described  in  a  spectrum  ranging  from  pure 
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behavior  that  is  free  from  structuiai  implications  to  pure  structure  that 
desctibes  the  interconnection  and  instantiation  of  hardware  components. 
A  procedure  instantiation  is  similar  to  instantiating  a  hardware  module, 
and  therefore  HardwareC  supports  fully  the  spectrum  of  design  description 
styles. 

4.  Specifies  Resource  Sharing  at  description  level  Although  it  is  not  required 
by  the  synthesis  system,  it  is  possible  for  a  designer  to  specify  the  sharing 
of  resources  (procedure  instances)  through  the  use  of  instantiating  pro¬ 
cedures.  For  example,  the  designer  can  specify  whether  only  one  adder 
should  be  used  to  implement  a  description  verses  one  that  uses  two  adders. 

9.3  Motivation  and  Example 

A  major  drawback  with  many  languages  is  the  inability  to  specify  exactly  which 
instance  of  a  given  procedure  is  invoked  in  a  procedure  call.  This  restriction  is 
reasonable  for  procedures  that  describe  only  the  functionality  without  internal 
state  information.  However,  if  a  procedure  has  internal  state  associated  with 
it  (through  the  use  of  either  static  or  register  variables),  such  restriction  sev- 
erly  handicaps  the  usability  and  expressiveness  of  the  language.  In  fact,  the 
such  deficiency  can  result  in  either  inefficient  or  even  incorrect  implementation, 
depending  on  whether  the  assumptions  made  by  the  synthesis  system  matches 
those  made  by  the  designer. 

Consider  the  description  of  a  counter  below. 

/- 

•  each  call  to  it  increments  by  1 

•/ 

counter(value) 

out  boolean  value  CS] ; 

{ 

static  state [8]; 

state  3  state  1; 
value  s  state; 
write  value; 

} 

Every  call  to  the  counter  module  will  increment  the  corresponding  internal 
state  variable  by  one.  If  a  call  is  made  to  counter  without  specifying  the 
particular  instance  that  is  to  be  invoked,  then  one  of  two  situations  will  arise. 

1.  Single  instance  assumption  -  If  the  synthesis  system  assumes  that  one  and 
only  one  instance  is  associated  with  a  procedure,  then  a  call  to  counter 


will  always  increment  the  same  internal  state  (corresponding  to  the  single 
instance). 

However,  this  approach  is  overly  restrictive  since  one  of  the  powers  of 
synthesis  systems  is  to  explore  the  spectrum  of  design  tradeoffs  between 
parallel  and  serial  implementations,  and  by  always  assuming  one  instance 
per  procedure  this  exploration  is  not  possible. 

2.  No  assumption  on  the  invoked  instance  -  On  the  other  hand,  if  no  assump¬ 
tions  are  made  on  which  instance  a  given  call  will  invoke,  the  synthesis 
system  will  then  have  the  flexibility  to  either  dedicate  an  instance  to  the 
call,  or  share  several  procedure  calls  onto  the  same  instance.  However, 
if  the  procedure  has  internal  state  information,  then  the  description  can 
be  incorrect,  dependent  on  the  particular  mapping  of  procedure  calls  to 
procedure  instances. 

The  assumptions  that  are  made  by  the  synthesis  system  may  not  be  what 
the  designer  had  in  mind  when  writing  the  description.  For  instance,  in  the 
code  segment  below,  counter  is  called  twice. 

counter (sunl) ; 

counter(suB2) ; 


The  designer  can  either  view  the  two  calls  as  incrementing  the  same  value 
twice,  or  he  can  view  the  two  calls  to  be  distinct,  each  incrementing  a  value 
independent  of  the  other.  Through  instantiation  of  procedures,  the  designer 
can  explicitly  specify  the  exact  semantics  of  a  procedure  call.  For  example,  if 
the  designer  wishes  to  increment  a  single  value  twice,  then  the  corresponding 
code  is  given  below. 

{ 

instance  counter  value; 

value ( — );  /•  increment  •/ 

value (...);  /•  increment  again  •/ 

} 

On  the  other  hand,  if  the  designer  wishes  to  increment  two  different  values, 
then  the  code  is  as  follows. 

{ 

instance  counter  valuel,  value2; 

valuel(...)  /•  increment  valuel  •/ 
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valu«2(...)  /•  increment  value2  •/ 

valuel(...)  /•  increment  valuel  again  */ 

> 

The  designei  can  instantiate  not  only  procedures,  but  also  procedure  tem¬ 
plates.  This  is  accomplished  by  supplying  the  values  to  the  integer  parameters 
to  the  corresponding  template,  separated  by  commas  if  more  than  one  vadue 
is  required.  The  example  below  makes  use  of  the  adder  template  described  in 
Section  8. 

■C 

instance  adder(4)  o4;  /•  4  bit  adder  •/ 

instance  adder(S)  o5;  /•  5  bit  adder  •/ 

o4(...): 

o5(...); 

> 

10  Operators 

HardwareC  supports  all  Boolean  and  relational  operators  available  in  the  con¬ 
ventional  C  programming  language.  It  also  supports  all  arithmetic  operators. 
The  operators  can  be  unary  or  binary,  and  take  both  integer  and  Boolean  vari¬ 
ables  as  operands.  Mixed  operations  between  Boolean  and  integer  variables  are 
also  allowed  if  it  makes  sense.  For  instance.  Boolean  inversion  on  an  integer 
variable  is  illegal. 

The  operators  are  summarized  below. 

Arithmetic  {  — .  -,»,/}  Applies  to  both  integer  and  Boolean  variables  and 
expressions. 

Boolean  {  !.  L.  xor  }  bitwise  Boolean  operators,  shift  left  (<<),  shift  right 
(>>),  rotate  left  (rl),  and  rotate  right  (rr).  Applies  to  only  Boolean 
variables  and  expressions. 

Relational  {  !  =,  ==,  <=,  >  =  ,  <.  >  }  Applies  to  both  integer  and  Boolean 
variables  and  expressions. 

Auto-Increment/Auto-Decrement  {  -^-r.  —  }  Applies  to  both  integer 
and  Boolean  variables  and  expressions.  For  example,  a  +  -•-  and  -r  a 

are  equivalent  to  o  =  o  -e  1,  whereas  a - and - a  are  equivalent  to 

a  =  a  -  1. 
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11  Input/Output 

HaidwaieC  has  explicit  input  and  output  conunands  to  aUow  reading  from  and 
writing  to  the  ports  of  a  process  or  procedure.  The  three  main  commands  are 
write,  free,  and  read,  and  are  described  below. 

write  writes  the  most  recently  assigned  ‘value'  of  an  output  or  inout  parameter 
onto  the  corresponding  ports.  Different  semantics  exist  for  different  types 
of  parameters;  they  are  surrunarized  below. 

•  No  write  is  specified  for  an  inout  or  out  parameter  -  any  change 
made  to  that  parameter  will  not  be  visible.  In  the  example  below, 
the  assignments  to  the  inout  parameter  a  do  not  affect  the  value 
of  the  port;  they  only  serve  to  alter  the  value  of  a  for  subsequent 
references. 

inout  boolean  a; 


a  =  1:  /•  port  unaffected  •/ 
a  s  0;  /•  port  unaffected  «/ 
a  »  1;  /•  port  unaffected  •/ 


•  Singe  write  to  an  out  parameter  -  in  many  situations,  the  designer 
wishes  to  connect  an  output  port  directly  to  the  result  of  a  particular 
operation.  There  are  two  advantages  for  using  direct  connection. 
First,  it  does  not  waste  a  state  at  run-time.  Second,  direct  connection 
allows  external  visibility  of  a  particular  operation. 

Direct  connection  is  achieved  by  specifying  a  single  write  for  an 
output  parameter  in  the  body  of  the  routine.  For  instance,  the  output 
parameter  z  is  connected  directly  to  the  output  of  the  adder  in  the 
example  below. 

uhila  (run)  f 

temp  3  temp  '*■  1 ; 
z  =  temp; 

write  z;  /•  direct  connection  */ 

} 

Any  value  written  to  a  port  will  be  retained  until  either  the  next  write  or 
free  statement.  In  the  example  below,  the  out  parameter  c  wrill  generate 
a  pulse  on  the  ports. 

out  boolean  c; 
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c  =  0 
9rit«  c; 

c  s  1; 
vTite  c; 

c  =  0 
vrita  c; 


/*  port  has  0 


/•  port  has  1 


/•  port  has  0 


•/ 

•  / 

again  •/ 


free  sets  the  corresponding  output  or  inout  port  to  high  impedance  float  value. 
For  both  free  and  write,  the  effect  of  the  change  on  port  boundary  will 
take  place  exactly  one  cycle  after  the  statement  begins  execution.  Any 
write  to  a  port  that  has  been  set  to  float  state  will  overwrite  it  with  the 
new  value.  For  example, 

out  boolean  d; 


d  =  1 

write  d;  /•  port  has  1  •/ 

free  d;  /•  port  has  high-Z  •/ 

write  d;  /*  port  has  l  again  */ 

read  samples  the  corresponding  in  or  inout  port  into  a  legistei,  and  returns 
the  output  of  the  sampling  register.  Execution  of  a  read  statement  will 
take  one  cycle  to  complete.  For  example. 

y  =  read(  x  ) ; 

/•  y  is  sampled  version  of  x  •/ 

12  Inter-Process  Communication 

There  are  two  paradigms  for  inter-process  communication  -  shared  medium  and 
message  passing.  Shared  medium  communication  refers  to  the  transfer  of  infor¬ 
mation  between  modules  through  a  common  set  of  ports.  The  protocol  which 
governs  correct  handshaking  between  the  modules  is  provided  by  the  designer, 
and  is  described  as  an  integral  part  of  the  high-level  description.  Message  pass¬ 
ing  communication,  on  the  other  hand,  utilizes  explicit  send  and  receive  opera¬ 
tions  to  synchronize  between  the  two  concurrent  processes. 
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Each  approach  has  its  advantages  and  limitations.  For  example,  in  com¬ 
munication  through  shared  medium,  the  performance  advantage  is  offset  by  an 
increase  in  the  complexity  of  the  resulting  high-level  description.  Likewise,  the 
conceptual  elegance  of  message  passing  solves  both  synchronization  and  commu¬ 
nication  in  systems,  but  may  result  in  unacceptable  implementation  complexity 
if  it  is  used  without  restraint. 

HardwareC  offers  both  approaches.  First,  it  allows  shared  medium  commu¬ 
nication  through  the  use  of  parameters  to  processes  or  procedures.  Second,  it 
allows  a  synchronous  send-receive  message  passing  scheme  with  fixed-size  mes¬ 
sages.  The  size  of  a  message  represents  the  number  of  bits  that  is  communicated 
between  the  processes,  and  may  be  specified  by  the  designer  in  the  input  descrip¬ 
tion.  Synchronous  message  passing  provides  a  simple  yet  powerful  approach  to 
inter-process  synchronization  and  limited  data  transfer  without  incurring  the 
cost  of  message  buffering. 

12.1  Message  Passing  Primitives 

There  are  three  primitive  operations  in  message  passing;  send,  receive,  and 
msgwait  Only  processes  can  use  the  message  passing  primitives,  send  transmits 
a  fixed  size  message  to  another  process.  The  current  process  will  wait  and 
synchronize  until  the  corresponding  process  issues  a  receive,  whereupon  the 
transfer  of  information  will  take  place.  For  example,  targetprocass  is  the 
receiving  process,  and  message  is  the  message  to  be  sent. 

sendC  targetprocess ,  message  ); 

receive  accepts  a  message  from  a  given  process,  and  will  wait  and  synchronize 
until  the  corresponding  process  issues  a  send.  For  example,  sourceprocess  is 
the  sending  process,  and  buffer  is  the  message  received. 

receiveC  sourceprocess,  buffer  ); 

msgviaii  is  a  query  that  returns  a  scalar  Boolean  flag  signifying  whether 
the  specified  process  is  currently  sending  to  the  current  process.  For  example, 
Producer  and  Consumer  are  two  processes  that  synchronize  with  each  other 
using  message  passing. 

process  Producer( _ ) 

< 

/«  generate  item  •/ 
send(  Consumer,  item  ); 

} 

process  ConsumerC _ ) 

{ 
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if  (  msgsalt (Producer)  ) 

{ 

receive (  Producer,  item  ); 

/*  consume  item  •/ 

} 

else 

/•  producer  not  ready  */ 

} 

Theie  is  a  system  wide  message  size,  which  is  the  bandwidth  of  the  commu¬ 
nication  channel  between  the  processes.  The  default  is  8  bits  wide,  and  it  can 
be  changed  by  specifying  the  size  in  the  description  as  follows. 

/a  <num>  is  nes  message  size  •/ 
ipcsize  =  const ant .number; 

ipcsize  is  a  keyword  in  the  language,  and  const  ant  .number  is  a  positive 
integer  constant.  The  message  size  change  must  be  done  before  any  message 
passing  operation  takes  place,  as  the  parser  will  check  to  ensure  proper  size 
messages  and  buffers  are  used  in  the  send  and  receive  operations.  The  assign¬ 
ment  should  not  be  within  the  body  of  any  particular  process  or  procedure,  and 
should  lie  between  procedural  definitions. 

13  Miscellaneous 

HardwareC  relies  on  the  C  preprocessor  during  parsing  to  handle  macro  defi¬ 
nition  (#define)  and  file  inclusion  (#include)  facilities.  The  designer  is  free  to 
use  any  C  preprocessor  commands  in  the  description. 


14  Appendix 

Four  detailed  examples  of  hardware  description  using  HardwareC  are  described 
below.  The  first  is  a  four  bit  carry  look-ahead  adder.  The  second  is  a  counter 
process  that  uses  the  four  bit  adder.  The  third  is  the  traffic  light  controller 
described  in  the  Mead-Conway  book.  The  final  example  is  the  Intel  8251  UART 
description. 

Four-Bit  Adder 

add^bm  a,  b,  carryin,  result,  carryout  ) 
in  boolean  a[4]; 
in  boolean  b[4]; 
in  boolean  carryin; 
out  boolean  result[4]; 
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out  booloan  carryout; 

int  i; 

boolaan  P[4],  G[4],  new; 

/• 

*  calculate  propagate  and  generate 

•/ 

lor  i  =  0  to  3  do 

P[i:i]  =  a[i:i]  xor  b(i;i]; 

for  i  =  0  to  3  do 

G[i:i]  =  a[i:i]  k.  b[i;i]; 

/• 

•  calculate  carryout 

■/ 

carryout  =  Gf3:3]  |  (P[3:3]  L  G[2:2]) 

I  (Pr3:3]  &  P[2:2]  k  Gfl;!]) 

I  (Pi3;3i  k  P{2;2]  k  P(l:li  k  G[0:0]) 

I  (Pi3:3]  k  Pf2;2]  k  P''l:i;  k  PfOrOj  k  carryin); 

/. 

«  calculate  sum 

•/ 

new  =  carryin; 

for  i  =  0  to  3  do  { 

result[i:i]  =  P[i:ii  xor  new: 
new  =  G[i:i]  |  (  P(i:ii  k  new  ); 

} 

writ*  result,  carryout; 


Counter 

process  counterC  run,  load,  updown,  data,  sun  } 

in  boolean  run, 
load,  updown, 
data [4] ; 

out  boolean  sun [4] ; 

< 

boolean  temp [5] ; 

while  (  run  )  { 
if  (  load  ) 

temp  =  data: 
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•1>«  -{ 

if  (  updosn  ) 

add4bit (temp .  1,  0.  temp [0:3].  temp[4:4]); 

else 

edd4bit  (temp ,  0x1,  0,  tenpCOiS],  teii^[4:4]); 

> 

sum  *  temp [0:3]; 
vrite  sum; 

} 

} 

Traffic  controller 

/• 

*  Nead/Convay  Trallic  Light  Controller 

•/ 

«  define  HIVAT.GREEN  0 
«  define  HIUAT.TELLOW  1 
«  define  FARM.GREEI  2 
«  define  FARM.TELLQV  3 

«  define  GREEN  1 
«  define  YELLOW  2 

*  define  RED  3 

#  define  TRUE  1 
«  define  FALSE  0 

process  traffic  (  run.  Cars, 

TimeoutL,  Timeouts, 

HiWayL,  FarmL,  StartTimer  ) 
in  boolean  run; 
in  boolean  Cars, 

TimeoutL, 

Timeouts ; 

out  boolean  HiWayLC2] , 

FarmL [2] , 

StartTimer ; 

i 

static  state [2]; 
boolean  nevstate[2]; 

vhile  (  run  )  { 
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/•  combiiutioiuil  logic 
to  datornino  aaxtatate 

•/ 

svitch  (state)  { 
case  HIUAT.GREEII : 

HiWayL  -  6REEH; 

FaxnL  >  RED; 

if  (Cars  *  TiaeoutL)  { 

neestate  =  HZViT.TEZXOV ; 
StartTimer  -  TRUE; 

}  else  { 

nenstate  =  HIUAT.GREEH; 
StartTimer  =  FALSE; 

} 

break; 

case  HIWAT.TELLOW : 

HiWayL  »  TELLaU; 

FaxnL  «  RED; 

il  (  Timeouts  )  { 

neestate  =  FARH.GREEH; 
StartTimer  =  TRUE; 

}  else  { 

neostate  =  FARH.TELLOW; 
StartTimer  =  FALSE; 

} 

break; 

case  FARH.GREEH: 

HiWayL  =  RED; 

FaxnL  »  GREEN; 

ii  (  !  Cars  I  TimeoutL  )  { 
neostate  -  FARH.TELLOW ; 
StartTimer  =  TRUE; 

>  else  { 

neostate  -  FARM.GREEN; 
StartTimer  =  FALSE; 

} 

break; 

case  FARH.TELLOW: 
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HiUayL  »  RED; 
FaxmL  =  TELLOU; 


il  (  TiaaotttS  )  { 

navstata  «  HIViT.GREEB; 
StartTiaar  -  TRUE: 

}  alaa  { 

naaatata  ^  FARM. YELLOW; 
StartTiaar  »  FALSE; 

> 

break; 

> 

state  =  nasstate; 

write  HiWayL,  FaraL,  StartTiaar; 

} 

> 


Intel  8251  UART  There  are  four  processes  -  main,  zmit.  syncjecv,  and 
asyncjecv.  They  communicate  through  send/receive  message  passing  primi¬ 
tives. 


/ 


i8251  UART  -  HardwaraC  version 


Written  by  David  Ku 
Stanford  University 


#  define 

#  define 

#  define 

#  define 
^  define 


DataSize 

forever 
waitCf ) 

TRUE 

FALSE 


8 

1 

while  (f) 

1 

0 


/• 

•  field  definition 

•/ 


«  define  eh  control [7: 7] 

#  define  ir  control [6: 6] 
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#  define 

rta 

control [S:S] 

*  define 

er 

control [4; 4] 

*  define 

8brk 

control [3 : 3] 

«  define 

rxE 

control [2: 2] 

t  define 

dtr 

control[l:l] 

t  define 

tzen 

control [0:0] 

t  define 

dsr 

atatua [7 : 7] 

«  define 

ayndet 

8tatua[6:6] 

t  define 

fe 

atatua [5 : 5] 

#  define 

oe 

atatua [4: 4] 

*  define 

P« 

atatua [3 : 3] 

*  define 

tze 

atatua [2: 2] 

«  define 

rxrdy 

atatua  Cl : l] 

#  define 

txrdy 

atatua [O : 0] 

#  define 

ac8 

■ode [7: 7] 

*  define 

nabita 

■ode [6: 7] 

#  define 

ead 

■ode [S : 5] 

«  define 

•P 

mode [4: 4] 

«  define 

pen 

■ode [3: 3] 

#  define 

nbita 

■ode  [l :  2] 

#  define 

brate 

mode  [O :  O] 

hunt_mod«() 

8«arch«8  in  8ynchronou8 
r«c8iv«  mod«  for  8ync  cbars 


hunt_inod«(  rxd,  drdy,  87ncl,  sync2,  mode  ) 
in  booloan  rxd; 
in  boolean  drdy; 
in  boolean  ayncl [DataSira] , 
83mc2C0ataSize] , 
mode [DataSiza] ; 

{ 

boolean  done; 
boolean  dataCOataSize] ; 
boolean  ncount [3] ; 

done  >  FALSE; 
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vhile  (  !  don«  )  i 


data  =  Oxtf; 

ahila  (  data  syncl  )  [ 

Bait  (  dzdy  ) ; 

data [7: 7]  >  read  (  rxd  ); 

data  =  data  »  1; 

done  =  TRUE; 

] 

if  {  mode [7:7]  0  )  { 


ncountC2:2]  =  1; 
ncountCO:!]  =  nbits; 

Bhile  (  ncount  )  [ 

Bait  (  dxdy  ) ; 
data[7:7]  =  rxd;- 
data  s  data  »  1 ; 
ncount  =  ncotut  -  1 ; 


> 


> 


} 


done  *  (data  *=  »ync2) : 


/• 

•  xmit  -  transmit  process 

•/ 


declare  process  i82Sl(ChipSelect, 

UriteEnable,  ReadEnable,  ChipData, 
data,  valid,  syncl,  sync2,  mode, 
control,  status) 
in  boolean  ChipSelect; 
in  boolean  WriteEnable; 
in  boolean  ReadEnable; 
in  boolean  ChipData; 
inout  boolean  dataCDataSize] ; 
out  boolean  valid; 
out  boolean  syncl [DataSize] ; 
out  boolean  sync2 [DataSize] ; 
out  boolean  node [DataSize] ; 
out  boolean  control [DataSize] ; 
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in  boolean  status [DataSize] ; 

process  xmitCcts,  tzd,  xdrdy,  valid, 
mode,  status,  control, 
syncl,  syncS) 
in  boolean  cts; 
out  boolean  txd; 
in  boolean  xdrdy; 
in  boolean  valid; 
in  boolean  syncl [DataSize] , 
aync2 [DataSize] ; 
in  boolean  mode [DataSize] , 

control [DataSize] ; 
out  boolean  status [DataSize] ; 

[ 

int  i; 

boolean  sync.mode;  /•  sync  mode  •/ 

boolean  sync.llag; 
boolean  data.ready; 
boolean  par; 

boolean  ncount[3];  /*  «  bits  •/ 

boolean  dbuf [DataSize] ; 
boolean  xdata [DataSize] ; 
boolean  okay [DataSize]  ; 

free  status ; 

/• 

•  initialization  -  valid 

■  true  when  syncl/sync2  is  ready 

•/ 

if  (  valid  )  { 

txd  -  1;  txe  =  0; 
write  txd; 

sync.mode  -  (mode[6:7]  --  0); 

/«  wait  for  enable  */ 
wait  (  txen  k  cts  ) ; 
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check  lor  sbrk 


/• 


*/ 


il  (!  eync.mode  k  sbrk) 

[  txd  -  0; 

vrite  txd: 

seit  (  (!sbrk)  I  (!txen)  I  (!cts)  }; 
txd  «  1 ; 
erlte  txd; 

3 

/* 

•  seit  if  in  async  mode, 

•  or  send  sync  char  if  sync 

•  / 

txe  =  1; 
erite  txe; 
free  txe; 


if  (  sync_node  ) 

{  /*  check  if  message  are  pending  «/ 

if  (  msgeaiting(i82Sl}  ) 

receive(i8251,  xdata) ; 

else 

{  if  (sync.flag) 

xdata  =  syncl ; 

else 

xdata  =  8ync2; 
sync .flag  =  !  sync.flag; 

} 

} 

else 

receive(i8251,  xdata); 


/• 

*  send  start  bit 

•/ 

if  (  !  sync.mode  ) 

[  salt  (xdxdy); 
txd  -  0; 
erite  txd; 

3 

/• 
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land  data 


« 

•/ 

neoiintC2:2]  *  1; 
ncount[0:l]  »  nbiti; 
vliila  (  ncount  ) 

[  salt  (xdrdj) ; 

txd  -  dbul Co ; 0] ; 
writ#  txd; 

ncount  s  ncount  -  1 ; 
dbul  =  dbu2  »  1; 

] 

/• 

•  land  parity  bits  if  required 

•  / 

if  (pan) 

C 

par  a  xdataC0:0]; 
for  i  =  1  to  7  do 

par  -  par  xor  xdataCi:!]; 

if  (!  ep) 

par  =  !  par; 
vait  (xdrdy) ; 
txd  a  par; 
orite  txd; 

] 

/• 

•  sand  stop  bits 

•/ 

if  ( !  sync.moda) 

[  sait  (xdrdy); 
txd  a  1 ; 
write  txd; 

] 

write  status: 

> 

] 

/• 

•  rcvr_sync  - 
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*  receiver  synchronous  process 

*/ 

process  rcvr.sync (rxd ,  drdy,  valid, 
mode,  control,  status, 
syncl ,  sync2) 

in  boolean  rxd;  /*  receive  serial  */ 

in  boolean  drdy;  /•  data  ready  */ 
in  boolean  valid; 
in  boolean  mode [DataSize] ; 
in  boolean  control [DataSize] ; 
in  boolean  syncl [DataSize]  ; 
in  boolean  aync2 [DataSize] ; 
out  boolean  status [DataSize] ; 

boolean  sync.mode; 
boolean  par; 
boolean  ncount [3] ; 
boolean  data [DataSize] ; 


/• 


•  / 


free  up  line 


free  status ; 

/• 

*  determine  initialization 

•  / 

if  (  valid  )  { 

sync.mode  =  (mode[6:7]  ==  0); 
if  (  sync.mode  )  [ 

/• 

•  wait  for  mode 

•/ 

if  (  eh  } 

hunt.mode(rxd,  drdy, 
syncl,  sync2,  mode  ); 

/• 
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start  shifting  data  in 


•  / 

ncountC2:2]  -  1; 
ncountCO:!]  *  nbits; 
nhila  (  ncount  )  [ 
aait  (  drdy  ) ; 
data [7: 7]  =  read  (  rxd  ): 
data  ~  data  >>  1 ; 
ncount  s  ncount  -  1 ; 

] 

/• 

•  send  data  to  main  process 

•/ 

send(  i82Sl ,  data  ) ; 
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write  status ; 

} 

> 

/• 

•  rcvr.async  - 

* 

•  receiver  asynchronous  process 

•/ 

process  rcvr_async(rxd,  drdyt  valid, 
mode,  control,  status) 

in  boolean  rxd;  /•  receive  serial  data  •/ 

in  boolean  drdy;  /•  data  ready  •/ 

in  boolean  valid; 

in  boolean  modeCDataSize] ; 

in  boolean  control [DataSize] ; 

out  boolean  status [DataSize] ; 

int  i; 

boolean  sync .mode; 
boolean  par; 
boolean  ncount [3] ; 
boolean  data [DataSize] ; 


/• 

m 

•/ 


dctflrminfl  initializatioc 


Iraa  statiu; 
if  (  valid  )  { 

/•  assuna  node  is  stable  nos  */ 
sync.moda  «  (niode[6:7]  ==  0); 
if  (  !  87nc_mode  )  [ 


/• 

•  Bait  for  start  bit 
*/ 

wait  (  rxd  ) ; 

Bait  (  !  rxd  ) ; 

/* 

•  start  shifting  data  in 

•/ 

ncount [2:2]  »  i ; 
ncount[0:l]  s  ubits; 

Bhile  (  ncount  }  [ 

Bait  (  drdy  ) ; 
data [7:7]  *  read  (  rxd  ) ; 
data  =  data  »  1  ; 
ncount  =  ncount  -  1 ; 

] 

/• 

•  sample  parity  bit 

•/ 

if  (  pen  )  [ 

par  s  data [0:0]; 
for  i  =  1  to  7  do 

par  =  par  xor  data[i:i] 

if  (  ep  ) 

par  s  !  par; 

Bait  (  drdy  ); 
if  (  par  !=  rxd  )  { 
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/•  parity  error  •/ 
pe  =  l: 
srite  pe; 

} 

] 

/• 

•  eanple  stop  bit 
*/ 

eait  (  drdy  ) ; 
il  (  rrd  *=  0  )  < 

/•  iraaiag  error  •/ 
le  =  1 ; 
write  fe; 

} 

/• 

*  send  data  to  main  process 

•/ 

send(  i82Sl ,  data  ) ; 


] 


} 


} 


write  status; 


/• 

m 

•/ 


main  process  for  intel  8251 


process  18251 (ChipSelect,  UriteEnable, 
ReadEnable,  ChipData,  data,  valid, 
syncl,  sync2,  mode,  control,  status) 
in  boolean  ChipSelect; 
in  boolean  VriteEnable; 
in  boolean  ReadEnable; 
in  boolean  ChipData; 
inout  boolean  data [OataSize] ; 
out  boolean  valid; 
out  boolean  syncl [DataSize] ; 
out  boolean  sync2 [DataSize] ; 
out  boolean  mode [DataSize] ; 
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out  boolean  control [DataSize] ; 
in  boolean  status [DataSize] ; 

boolean  modebul [DataSize] ; 
boolean  dbul [DataSize] : 
boolean  decode [3] ; 
boolean  sync.mode; 

valid  =  0; 
write  valid; 

/• 

•  reset  sequence :  read  mode  character 

•/ 

wait  (  ChipSelect  k  WriteEnable  t  ChipData  ) ; 

modebuf  =  read  (  data  ) : 

node  =  modebul ; 
valid  -  1; 

sync.mode  =  (modebul[6:7]  =x  o); 


/• 

•  read  sync  characters  if  necessary 

•/ 

syncl  =  0; 
sync2  =  0; 

if  (  sync.mode  ) 

[  /•  read  first  sync  char  •/ 

wait  (ChipSelectAWriteEnabletChipData) ; 
syncl  s  read  (  data  ) ; 

/•  read  second  sync  char  */ 

.  if  (  !  modebuf[7:7]  ) 

[  wait  (ChipSelectAWriteEnableJtChipData) ; 
sync2  »  read  (  data  ) ; 

] 

] 

/•  write  to  output  port  •/ 
write  valid,  node,  syncl,  sync2; 
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Bain  Intarp  loop 


/• 

.•/ 

d«cod«C0:0]  s  ChipOata; 
dacoda  Cl : l]  =  RaadEaabla ; 
dacodaC2:2]  s  WritaEnabla; 

shila  (  CbipSalact  ) 

{  switch  (dacoda)  { 

casa  0x2:  /•  raad  data  */ 

C 

if  (8ync_moda) 

racaiva(rcvr_sync,  dbuf ) ; 

alsa 

racaivaCrcvr.async,  dbuf); 

wait  (  !  WritaEnabla  ) ; 
data  3  dbuf; 
vrita  data; 

] 

break; 

casa  0x3:  /*  read  status  *■! 

[ 

data  -  read  (  status  ) ; 
wait  (  !  WritaEnabla  ) ; 
write  data; 

] 

break; 

casa  OxC:  /•  write  data  •/ 

dbuf  -  raad  (  data  ) ; 
sand(xBit,  dbuf); 
break; 

casa  OxD:  /•  write  control  •/ 

dbuf  -  raad  (  data  ) ; 
control  =  dbuf; 
write  control; 
break; 

> 

> 


] 


43 


References 

[1]  David  C.  Ku,  G.  De  Micheli,  HERCULES  -  A  System  for  High-Level 
Synthesis  Proceedings  of  the  25*^  ACM/IEEE  Design  Automation  Con¬ 
ference,  Anaheim,  1988. 

[2]  David  C.  Ku,  G.  De  Micheli,  Using  the  HERCULES  High-Level  Syn¬ 
thesis  System  Internal  report,  1988 

[3]  Frederic  Mailhot,  G.  De  Micheli,  Struetnral/ Logic  Intermediate  Form 
Specification  Internal  report,  1988 

[4]  Robert  Alverson,  Tom  Blank,  et.  al.,  THOR  User’s  Manual:  Tutorial 
and  Commands  Stanford  Technical  Report  CSL-TR-88-348,  January. 
1988 


44 


